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IANA Registration of Enumservices for Internet Calendaring 
Abstract 


This document registers Enumservices for Internet calendaring. 
Specifically, this document focuses on Enumservices for scheduling 
with iMIP (iCalendar Message-Based Interoperability Protocol) and for 
accessing Internet calendaring information with CalDAV (Calendaring 
Extensions to WebDAV). 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright and License Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
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not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


1. Introduction 


ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS 
(Domain Name System, RFC 1034 [2]) to translate telephone numbers, 
such as ’+12025550100’, into URIs (Uniform Resource Identifiers, RFC 
3986 [3]), such as /mailto:user@example.com’. ENUM exists primarily 
to facilitate the interconnection of systems that rely on telephone 
numbers with those that use URIs to identify resources. The ENUM 
registration here could be used to allow phones, for example, to 
check the free/busy status of a user in their address book or propose 
a meeting with him or her from the user’s phone number. 


The Guide to Internet Calendaring [10] describes the relationship 
between various Internet calendaring specifications like this: 
"iCalendar [4] is the language used to describe calendar objects. 
iTIP [5] [iCalendar Transport-—Independent Interoperability Protocol] 
describes a way to use the iCalendar language to do scheduling. iMIP 
[6] [iCalendar Message-Based Interoperability Protocol] describes how 
to do iTIP scheduling via e-mail". 


Recently, another Standards Track protocol for calendar and 
scheduling access has appeared. CalDAV (Calendaring Extensions to 
WebDAV) [7] is a WebDAV (Web-based Distributed Authoring and 
Versioning) [8] based mechanism for manipulating Internet calendars, 
viewing free/busy lists, and via a planned scheduling extension [15], 
could be used for proposing calendar events as well in the future. 


The existing ’mailto:’ URI scheme (defined in RFC 3986 [3]) is 
already used to address iMIP compatible Calendar Services. Likewise, 
the existing /’http:’ and ’https:’ URI schemes (defined in RFC 2616 
[11] and RFC 2818 [12]) are already used to address CalDAV compatible 
Calendar Services. 


This document registers Enumservices for scheduling and accessing 
Internet calendaring information associated with an E.164 number. 
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2's 


Enumservice Registrations 


As defined in RFC 3761 [1], the following templates cover the 
information needed for the registration of the Enumservices specified 
in this document: 


Enumservice Name: 
"ical-sched" 
Enumservice Type: 
"ical-sched" 
Enumservice Subtypes: 
"mailto" 
URI scheme (s): 
‘"mailto:’ 
Functional Specification: 
This Enumservice indicates that the resource identified can be 
addressed by the associated URI used for scheduling using Internet 
calendaring via Internet mail with the iMIP [6] protocol. 
Security considerations: 
See Section 4. 
Intended usage: 
COMMON 
Author: 
Rohan Mahy (rohan@ekabal.com) 


Enumservice Name: 
"ical-access" 
Enumservice Type: 
"ical-access" 
Enumservice Subtypes: 
" http" 
URI scheme (s): 
PREtDs” 
Functional Specification: 
This Enumservice indicates that the resource identified can be 
addressed by the associated URI in order to access a user’s 
calendar (for example free/busy status) using the CalDAV [7] 
protocol for Internet calendaring. 
Security considerations: 
See Section 4. 
Intended usage: 
COMMON 
Author: 
Rohan Mahy (rohan@ekabal.com) 
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Enumservice Name: 
"ical-access" 
Enumservice Type: 
"ical-access" 
Enumservice Subtypes: 
"https " 
URI scheme (s): 
'https:” 
Functional Specification: 
This Enumservice indicates that the resource identified can be 
addressed by the associated URI in order to access a user's 
calendar (for example free/busy status) using the CalDAV [7] 
protocol for Internet calendaring. 
Security considerations: 
See Section 4. 
Intended usage: 
COMMON 
Author: 
Rohan Mahy (rohan@ekabal.com) 


Note: These Enumservices use a dash "-" in the Type strings. To 
allow for hierarchical concepts (as required in this case), some kind 
of boundary needs to be in place. Neither RFC 3761 [1] nor its 
intended successor [17] foresee the concept of sub-subtyping. The 
natural solution to address this requirement is the usage of dash "-" 
in Type strings, which is slightly contradictory to RFC 3761 [1]. 


However, its intended successors [16] [17] clearly allow a dash "-" 
in Type strings, so that using "-" is seen as a practical way 
forward. 


3. Examples 


SORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. 
@ NAPTR 10 100 "u" "E2U+ical-access:https" \ 
"1^. *$!https://cal.example.com/home/alice/calendars/!" 


SORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. 
@ NAPTR 20 100 "u" "E2U+ical-sched:mailto" \ 
"I!4,.*S!mailto:alice@example.com!" 


4. Security Considerations 


The Domain Name System (DNS) does not make policy decisions about 
which records it provides to a DNS resolver. All DNS records must be 
assumed to be available to all inquirers at all times. The 
information provided within an ENUM record set must therefore be 
considered open to the public -- which is a cause for some privacy 
considerations. 
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Revealing a calendaring URI by itself is unlikely to introduce many 
privacy concerns, although, depending on the structure of the URI, it 
might reveal the full name or employer of the target. The use of 
anonymous URIS mitigates this risk. 


As ENUM uses DNS, which in its current form is an insecure protocol, 
there is no mechanism for ensuring that the answer returned to a 
query is authentic. An analysis of threats specific to the 
dependence of ENUM on the DNS is provided in RFC 3761 [1], anda 
thorough analysis of threats to the DNS itself is covered in RFC 3833 
[14]. Many of these problems are prevented when the resolver 
verifies the authenticity of answers to its ENUM queries via DNSSEC 
(DNS Security, RFC 4035 [9]) in zones where it is available. 


More serious security concerns are associated with potential attacks 
against an underlying calendaring system (for example, unauthorized 
modification or viewing). For this reason, iTIP discusses a number 
of security requirements (detailed in RFC 2446 [5]) that call for 
authentication, integrity and confidentiality properties, and similar 
measures to prevent such attacks. Any calendaring protocol used in 
conjunction with a URI scheme currently meets these requirements. 

The use of CalDAV with the ’https:’ scheme makes use of TLS 
(Transport Layer Security, RFC 5246 [13]) to provide server 
authentication, confidentiality, and message integrity. 


Unlike a traditional telephone number, the resource identified by an 
calendaring URI is often already guessable, and it often requires 
that users provide cryptographic credentials for authentication and 
authorization before calendar data can be exchanged. Despite the 
public availability of ENUM records, the use of this information to 
reveal an unprotected calendaring resource is unlikely in practice. 


5. IANA Considerations 
This document requests registration of the "ical-sched" and "ical- 
access" Enumservices according to the definitions in Section 2 of 
this document and RFC 3761 [1]. 
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